In recent years, along with improvement in the arrangement of communication infrastructures and wide distribution of LANs (local area networks) and internet services, there have been progressed remarkable developments in distributed computing systems from which terminal computers can enjoy desired services via a network. According to a conventional integrated data-processing type host-computer system, a high-performance host computer has carried out a necessary processing for the utilization of a database or for a complex calculation. Based on this arrangement, a plurality of terminals connected to the host computer have been able to enjoy desired services.
The distributed computing system that has replaced the host-computer system utilizes high-performance personal computers (PCs) and workstations (WSs) that are available at low cost in recent years. In the distributed computing system, server machines provide highly reliable services by high-speed processing of large volume of data. Client machines such as the PCs and the WSs carry out data processing and take user interfaces in this system. These client machines and server machines are connected together by a network. In this way, the distributed computing system achieves what is called a client/server system based on the distributed processing.
A network programming for achieving the distributed computing is usually carried out based on an RPC (a remote procedure call). The RPC is a programming for calling procedures (such as functions) that are located at different positions of the network. Procedures for utilizing the network are prepared in each server as a library. Through this library, clients can utilize the network.
Therefore, when the library of the procedures is arranged in each server, it is possible to carry out a network programming without being conscious about the network structure, protocols and communications between processes. Based on this RPC, a client can feel as if the procedures in the server were at the client side, and it is possible to shelter data transfers in the network and data conversions between the machines.
However, as the scale of the network becomes larger and the applications for providing the above services become higher functional, there have been problems of increase in the communication traffics and increase in the load of servers. Further, the development of applications becomes more complex. Particularly, the application development has so far been progressed by using development languages and development tools that are different for each operating system (OS). However, when the network has become widely distributed, the conventional method of separately carrying out the application development and the build up of installation environment including communication and resource management and fault measures becomes a heavy load on the application development staffs. This method also provides a lot of difficulties to these development staffs.
In order to solve these problems, a distributed object technique for further increasing the distribution of processing units and reutilization of application components in the network programming has come to attract attention. In this case, the object refers to a program having data and a processing procedure (called a method or an operation) integrated together. In the distributed object system, objects can dynamically structure a client/server relationship for a certain processing and carry out this processing so that the total network can function as one huge computer.
As a representative architecture of distributed objects, there is CORBA (Common Object Request Broker Architecture) set forth by OMG (The Object Management Group) that is an object-oriented technique standardization group in the USA. A standard specification of the distributed object management provided by a CORBA will be explained below.
Originally, there was proposed a mutual communication system called an ORB (Object Request Broker) as a framework for sharing application components that are distributed on the network. Based on the ORB, a program for executing a service on the network is regarded as an object. A client program (that is, a client object) can call a method of a server object on the same machine or on the network through this ORB without being conscious about where this method is located.
The ORB manages the information about the machine on the network in which an object exists. It is not necessary to designate the name of the machine at the time of calling a service. Therefore, in the case of moving a certain service from one machine to a separate machine in the application that utilizes the ORB, all what is needed for a client is to change the setting of the service on the ORB without the need for changing the program. This makes it possible to improve the flexibility of the application.
Accordingly, a client sends via the ORB a processing request to an object that the client wants to utilize. The object that has received this request executes the processing and returns a result of the processing to the client via the ORB. In this case, the client means a user of an object, and a server is a provider of the object that is utilized. (This object will hereinafter be called an object implementation in order to distinguish between this object and a general object.) A separate server may become a client of an object implementation. Therefore, the object on the ORB may become a client object or a server object depending on the situation.
Further, distributed objects on the ORB need to be able to be described in the form independent of a program language as well as being able to be dependent on machine and system languages. Therefore, this requirement is met by introducing a language called IDL (an interface definition language). Unlike other languages, the IDL is an exclusive language for defining only the interface. This IDL declares a set of operations, exceptions and attributes. Each operation consists of signatures that define a name, a parameter, a result and exceptions.
The CORBA is a standardization specification of the ORB. Particularly, at the time of sending a request from a client to the ORB, the language (C, C++ or the, like) of a program at the client side (a client application) is combined with the ORB to facilitate communications of messages between both parties. This method is called binding. There are two types of binding methods, a static startup and a dynamic startup. In order to design an object of the CORBA, at first, only a publicized function of the object is defined by using the IDL. Based on this IDL, various programming languages are loaded.
FIG. 26 is a block diagram that shows an interface structure of the ORB in the CORBA. The interface of the CORBA shown in FIG. 26 consists of an ORB core 2600, a dynamic startup interface 2650, a client stab 2660, an ORB interface 2670, an object adapter 2680, a server skeleton 2690, an interface repository 2630, and an implementation repository 2640.
In FIG. 26, the ORB core 2600 is for performing communications between a client 2610 and a server (an object implementation) 2620 without depending on a position. In general, the ORB core 2600 is interpreted to have a function of defining an object bus. This object bus can be expanded by the interface repository 2630, the implementation repository 2640 or other CORBA services.
At the time of a dynamic startup, the dynamic startup interface 2650 takes out information on the type of an object to be linked at the time of executing the object (hereinafter to be referred to as a target object) and calls the target object. The interface specification of the dynamic startup is common to each object.
The client stub 2660 is a function mapped with an interface definition of the target object. This defines a method for the client 2610 to start the target object on the server 2620. Therefore, when the client application is prepared, the client stub 2660 is generated in advance for each type of target object. The client stub 2660 is for calling the target object at the time of carrying out the static startup.
The ORB interface 2670 is an interface for operating the ORB, and this consists of a few APIs (Application Programming Interfaces) for local services that are required by the application. For example, the ORB interface 2670 provides the API that converts an object reference for referring to an object into a character string or for carrying out the opposite conversion.
The object adapter 2680 receives a request for a service on behalf of an object implementation, generate the object implementation, transfers the request to the object implementation, and provides an execution environment for allocating an object reference. Particularly, when a target object has been called at first in the ORB, a process is generated (that is, an object is activated). The object adapter 2680 mainly activates and inactivates the object.
The server skeleton 2690 provides a static interface to respective services that are exported by the server 2620. In other words, the server skeleton 2690 restores the structure converted by the client stub 2660, into an original function call format, and calls the implementation code of the target object. The server skeleton 2690 is generated together with the client stub 2660 by using an IDL compiler.
Although not shown in FIG. 26, it is assumed that a dynamic skeleton interface for providing the server with a function equivalent to that of the dynamic startup interface 2650 at the client side, is also included in the server skeleton 2690. This dynamic skeleton interface is the API for providing a method of delivering a request from the ORB to the object implementation when the implementation type of the target object is not clear at the time of generating a client application.
At the time of a dynamic startup, the interface repository 2630 stores in the form of an object the interface information prepared in the IDL to be taken out at the time of executing the object. The implementation repository 2640 provides the class to be supported by the server 2620, the generated object, and the repository at the time of executing the object.
Next, the development of the client application in the distributed object system based on the above-described CORBA specification will be explained. FIG. 27 is a flowchart that shows a conventional process of developing a client application. Particularly, the flowchart in FIG. 27 shows the process of developing the client application for carrying out the static startup.
Referring to FIG. 27, at first, a client application development staff designs a program interface of a client application to be developed (at a step S2701). Then, the client application development staff prepares an IDL file of a function to be called in the client application, that is, an object class (at a step S2702). The IDL is a means for guiding a client candidate about what kind of operation the object can provide and how to start the object. The IDL defines a type of the object, attributes of the object, a method that the object exports, and a parameter of the method.
Then, the staff prepares a source of a desired client application to be executed by using the object class (at a step S2703). For executing the client application, a server is necessary that provides the object class. Therefore, a server application is necessary in order to verify or test the execution of the client application that has been prepared at the step S2703.
However, when the server application that has been in actual operation on the network is used for verifying the execution of the program, there is a risk that this server application is destroyed depending on the client application tested or that this gives inconvenience to other objects on the network. Therefore, the use of the server application for the verification in this way is not practical.
In order to solve this problem, usually, a test server application is prepared (at a step S2704). The verification of the execution of the prepared client application is carried out under the environment that this test server application has been started.
Next, the IDL file that has been prepared at the step S2702 is compiled by using an IDL compiler, thereby to generate a client stab, a server skeleton and an IDL object (at a step S2705). The IDL object is combined with the interface repository (at a step S2706), and thus becomes IDL information that is used at the time of carrying out the dynamic startup.
The client application that has been prepared at the step S2703 is compiled to generate an object. This object is linked with the client stab generated at the step S2705, thereby to obtain an executable client application file (at a step S2707).
Similarly, the test server application prepared at the step S2704 is compiled to generate an object. This object is linked with the server skeleton that has been generated at the step S2705, thereby to obtain an executable test server application file (at a step S2708).
The test server application that has been obtained at the step S2707 is stored in the implementation repository, and this test server application is also registered as an object implementation that can be called by the server application (at a step S2709).
In order to carry out the verification of the execution of the client application that has been prepared, a test data is prepared that becomes a text image to respond to a request transmitted from the client (at a step S2710). Next, the test server application registered at the step S2709 is started (at a step S2711). In this state, the client application generated at the step S2707 is executed, and a result of this execution is verified (at a step S2712).
On the other hand, in the case of developing the server application, it is also necessary to prepare a test client application in a similar manner to that for the development of the client application as described above. FIG. 28 is a flowchart that shows a conventional process of developing the server application. The flowchart of FIG. 28 also shows the process of developing the server application for carrying out the static startup.
Referring to FIG. 28, at first, a server application development staff designs a program interface of a server application to be developed (at a step S2801). Then, the server application development staff prepares an IDL file of a function to be called in the server application, that is, an object class (at a step S2802).
Then, the staff prepares a source of a desired server application to be executed by using the object class and a source of a test server application (at steps S2803 and S2804). Next, the IDL file that has been prepared at the step S2802 is compiled by using an IDL compiler, thereby to generate a client stab, a server skeleton and an IDL object (at a step S2805). The IDL object is combined with the interface repository (at a step S2806).
The server application that has been prepared at the step S2803 is compiled to generate an object. This object is linked with the client stab generated at the step S2805, thereby to obtain an executable server application file (at a step S2807).
Similarly, the test client application prepared at the step S2804 is compiled to generate an object. This object is linked with the client stab that has been generated at the step S2805, thereby to obtain an executable test client application file (at a step S2808).
The server application that has been obtained at the step S2808 is stored in the implementation repository, and this server application is also registered as an object implementation that can be called by the test client application (at a step S2809).
In order to carry out the verification of the execution of the server application, a test data (a text image) to be transmitted from the test client application to the server application is prepared (at a step S2810). Next, the server application registered at the step S2809 is started (at a step S2811). In this state, the test client application generated at the step S2807 is executed, and an operation result of the server application obtained according to this execution is verified (at a step S2812).
As explained above, the distributed object system uses a client/server model as a basic structure. Therefore, for the execution of an application, usually a client and a server are necessary as a pair. At the stage of development of an application, in order to verify the execution of an application that has been prepared, it is also necessary to prepare the application that operates on the client and the server as a pair.
As another method of developing an application in the distributed object system, there has been proposed, for example, “A system and a method for a distributed debugging for debugging distributed application programs” as disclosed in Japanese Patent Application Laid-open Publication No. 9-120366. According to this “A system and a method for a distributed debugging for debugging distributed application programs”, a debugger engine is made resident in each of local computers and remote computers under a distributed object environment based on the CORBA. Also, a debugger GUI is provided in at least one of these local computers and remote computers.
The debugger GUI communicates with the debugger engines based on the communication mechanism so that a client application can use the debugger in the local host. The debugger can debug in seamless the applications that include objects and object implementations that operate in remote computers.
However, according to the distributed object system based on the CORBA, it is not the development staff but the ORB that recognizes a position of the application (object) and the interface that becomes the communication party. Except a special case that the client application development staff is also the server application development staff, the development staff is required to communicate with unknown objects disposed on unknown host systems.
In other words, according to the CORBA-based system, the client application does not directly obtain the position where the target object is disposed, and the client application can only use the target object. In general, the application development staff of the CORBA-based system cannot find the server that is relevant to his or her own object.
Therefore, in order to develop an application that is operated on the distributed object system based on the CORBA specification, it has been necessary to prepare a test client application or a test server application separate from a target client application or a target server application, as described above. In order to increase the reliability of the verification of the execution of the target application, it is not allowed to include a bug in the test application. Therefore, this requirement has been a very heavy load on the application development staff.
Further, according to the distributed object system based on the CORBA specification, the above-described IDL is introduced in order to eliminate the dependence on the application language and the OS dependence. On the other hand, the application development staff is required to master the language called the IDL in addition to the application program language. The staff also needs to verify that the IDL has been correctly input and output in the verification of the execution of the prepared application. According to the conventional procedures for developing applications shown in FIGS. 27 and 28, the environment for developing the client application and the environment for developing the server application are not separated. Therefore, it is not possible to completely reenact the application operation particularly on the ORB under the actual environment of the distributed objects via the network. Accordingly, it has been necessary to prepare a client request or a server response according to the architecture (such as the OS) dependent on the system (host system) that actually carries out the verification of the execution.
Further, according to the “A system and a method for a distributed debugging for debugging distributed application programs” as disclosed in Japanese Patent Application Laid-open Publication No. 9-120366, the debugging is realized under the environment of the actual distributed objects. Therefore, it is possible to carry out a more reliable verification of the execution of the application. On the other hand, there is a risk that the existence of a bug gives a bad influence to other nodes (other clients or servers) connected to the network.
Further, it is necessary to mount a debugger machine onto the machine of the server application or the client application that forms a pair with the server application or the client application of which execution is to be verified. However, when it is not possible to know an accurate position of the target object based on the CORBA specification, particularly when a dynamic startup is to be carried out, it is not practicable to mount a debugger machine on each of the servers that have target objects.